Partial expression evaluation, example of a builtin function #1115

andrzej-krupka · 2025-06-02T20:42:01Z

No description provided.

…e current structure causes circular import

…ontains cyclic imports but only runtime, never at init...)

flow360/component/simulation/blueprint/core/__init__.py

flow360/component/simulation/blueprint/core/context.py

andrzej-krupka · 2025-06-02T21:02:10Z

flow360/component/simulation/blueprint/core/expressions.py

+    def evaluate(
+        self,
+        context: EvaluationContext,
+        raise_error: bool = True,


strict has been renamed to raise_error, feels more verbose.

force_evaluate basically means that we don't evaluate blacklisted symbols at all, thus yielding "partial evaluation" that we needed.

As an example:

from flow360 import control, math x = UserVariable(name="x", value = 1) # Works with python model.expression = math.cross([x, 2 * x, 1], control.machRef) # Also works with strings... model.expression = "math.cross([x, 2 * x, 1], control.machRef)" # When converting to solver, cross is inlined: # [ # (2 * x) * ((solution.coordinate)[2]) - (1 * ((solution.coordinate)[1])), # 1 * ((solution.coordinate)[0]) - (x * ((solution.coordinate)[2])), # x * ((solution.coordinate)[1]) - ((2 * x) * ((solution.coordinate)[0])) # ]

I propose raise_error -> raise_on_non_evaluable
force_evaluate -> evaluate_numerically

something like these.

First one I agree with. For the second one I stand by force_evaluate, because the flag changes the behavior on handling symbols that return False for can_evaluate (solver variables in our case), essentially forcing those symbols to be evaluated to a numeric value. I think evaluate_numerically would fit if we changed evaluable and can_evaluate to something like numeric and has_numeric_value respectively.

Changed raise_error to raise_on_non_evaluable

andrzej-krupka · 2025-06-02T21:05:32Z

flow360/component/simulation/user_code/core/types.py

-    pattern = f"({'|'.join(escaped_delimiters)})"
-    result = re.split(pattern, value)
-    return [part for part in result if part != ""]
+def __soft_fail_sub__(self, other):


This is a port of #1092

are we overloading enough operators?

I think we need to overload all binary operators that have a left and right version. I'll double check and write a test for it.

flow360/component/simulation/user_code/core/utils.py

flow360/component/simulation/unit_system.py

flow360/component/simulation/blueprint/core/expressions.py

benflexcompute · 2025-06-03T02:09:00Z

There are cyclic pylint errors. I have not got chance to take a look.

tests/simulation/test_expressions.py

andrzej-krupka · 2025-06-03T09:47:20Z

There are cyclic pylint errors. I have not got chance to take a look.

Yup, in context.py there are cyclic imports, but I believe in this specific case they're needed. Here's my reasoning:

When the user_code module is imported the use can request the module to evaluate an expression. When he does that, the expression body (a string) gets parsed into an AST and the nodes are evaluated. For name nodes we need to resolve those string names to valid python objects. We expose multiple modules (for example units, variables, math functions and possibly more to come in the future...) and we cannot guarantee they are imported at the time of evaluation. This is why we need to dynamically import them as we evaluate the expression at runtime.
To my understanding of Python circular imports only cause errors when we try to import modules that are not initialized fully (so usually for top-level imports). Since expression string evaluation only happens after the modules are fully initialized and the circular imports are not top-level we should not run into issues (solver variables which are initialized along with the modules are a bit tricky but since unit system imports are not circular its not an issue, I think we could run into issues if we, for example, used a math function within a solver variable value definition which doesn't happen.

benflexcompute · 2025-06-04T19:52:15Z

flow360/component/simulation/blueprint/core/generator.py

-        if len(expr.elements) == 1:
-            return f"{{{elements[0]}}}"
-        return f"{{{', '.join(elements)}}}"
+            return "std::vector<float>()"


I am a bit confused. What is the use case of this? What expression would trigger this line?

I believe (,) would being an empty tuple declaration. Considering we are not using it perhaps would be better to just disallow it.

OK changed to error for stricter checking

benflexcompute · 2025-06-04T20:38:39Z

flow360/component/simulation/blueprint/core/generator.py

@@ -158,8 +157,8 @@ def _list(expr, syntax, name_translator):
        return f"[{elements_str}]"
    if syntax == TargetSyntax.CPP:
        if len(expr.elements) == 0:


Same here. Should we throw exception in this case?

In the general case its still a valid python syntax so it makes some sense to have this. It will just fail in the validator for any DimensionedType so technically it is never reached for our use cases.

OK changed to error for stricter checking

benflexcompute · 2025-06-04T20:51:24Z

flow360/component/simulation/blueprint/core/types.py

-
+            force_evaluate (bool): If True, evaluate evaluable objects marked as
+                          non-evaluable, instead of returning their identifier.
+            inline (bool): If True, inline certain marked function calls.


Do we still need this line?

Whoops, nope. It's a leftover. Will remove.

benflexcompute · 2025-06-05T13:10:15Z

flow360/component/simulation/blueprint/core/generator.py

@@ -158,8 +157,8 @@ def _list(expr, syntax, name_translator):
        return f"[{elements_str}]"
    if syntax == TargetSyntax.CPP:
        if len(expr.elements) == 0:


OK changed to error for stricter checking

benflexcompute · 2025-06-05T13:10:22Z

flow360/component/simulation/blueprint/core/generator.py

-        if len(expr.elements) == 1:
-            return f"{{{elements[0]}}}"
-        return f"{{{', '.join(elements)}}}"
+            return "std::vector<float>()"


OK changed to error for stricter checking

benflexcompute and others added 5 commits May 30, 2025 02:15

Cross in Pyhton mode works

7e41f4b

WIP now needing for refactor to enable function on-demand import sinc…

e7347a3

…e current structure causes circular import

Some comments

be624c4

Got symbolic evaluation to work but very HACKY

7f2f45b

Refactored expressions module structure to be self-contained (still c…

8db30c1

…ontains cyclic imports but only runtime, never at init...)

andrzej-krupka force-pushed the andrzej/partial-expression-evaluation branch 2 times, most recently from 0c0de3a to e9420d9 Compare June 2, 2025 21:09

andrzej-krupka commented Jun 2, 2025

View reviewed changes

Partial evaluation before solver code translation

5e7e746

andrzej-krupka force-pushed the andrzej/partial-expression-evaluation branch from e9420d9 to 5e7e746 Compare June 2, 2025 21:11

More fixes, simplify deserializer logic

135f14c

benflexcompute reviewed Jun 3, 2025

View reviewed changes

flow360/component/simulation/unit_system.py Outdated Show resolved Hide resolved

benflexcompute added 3 commits June 3, 2025 00:53

Format

97b68b7

Fixed unit test as many as possible, only 1 left

073f7e9

Fixing most of the pylint issues

e63d85c

benflexcompute reviewed Jun 3, 2025

View reviewed changes

flow360/component/simulation/blueprint/core/expressions.py Outdated Show resolved Hide resolved

benflexcompute reviewed Jun 3, 2025

View reviewed changes

tests/simulation/test_expressions.py Outdated Show resolved Hide resolved

Andrzej Krupka and others added 5 commits June 3, 2025 15:26

Fixed allow_inf_nan when evaluating expressions with solver variables

a50bb0b

eagerly evaluation and also taking advantage of unyt pacakge

eb4b2c8

Small fixes

9afab83

Fix invalid list initialization syntax in the C++ code generator

ee3c7f9

Added back the as_vector() implementation

b24e20d

benflexcompute closed this Jun 4, 2025

benflexcompute reopened this Jun 4, 2025

Renamed raise_error

eeb849c

benflexcompute approved these changes Jun 5, 2025

View reviewed changes

andrzej-krupka force-pushed the andrzej/partial-expression-evaluation branch from 145584b to 00f639c Compare June 5, 2025 14:32

Remove extra evaluation call in cross, reduce unnecessary parentheses

1c67711

andrzej-krupka force-pushed the andrzej/partial-expression-evaluation branch from 00f639c to 1c67711 Compare June 5, 2025 14:48

benflexcompute approved these changes Jun 5, 2025

View reviewed changes

some more small changes

139647e

benflexcompute enabled auto-merge (squash) June 5, 2025 15:11

Format

4aeb42f

benflexcompute merged commit 61beaf5 into expressions Jun 5, 2025
3 checks passed

benflexcompute deleted the andrzej/partial-expression-evaluation branch June 5, 2025 15:15

Partial expression evaluation, example of a builtin function #1115

Partial expression evaluation, example of a builtin function #1115

Uh oh!

Conversation

andrzej-krupka commented Jun 2, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benflexcompute commented Jun 3, 2025

Uh oh!

Uh oh!

andrzej-krupka commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

andrzej-krupka commented Jun 3, 2025 •

edited

Loading